home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Technotools
/
Technotools (Chestnut CD-ROM)(1993).ISO
/
lantools
/
odiup5a
/
readme.doc
< prev
next >
Wrap
Text File
|
1992-02-03
|
76KB
|
2,653 lines
ODI for DOS
User's Guide
June 1991 Edition
Novell, Incorporated
122 East 1700 South
P.O. Box 5900
Provo, Utah 84606 USA
■ Copyright 1991 Novell, Inc. All rights reserved. No part
of this publication may be reproduced, photocopied, stored on
a retrieval system, or transmitted without the express prior
written consent of the publisher.
Novell Part # 100-000871-002Disclaimer
Novell, Inc. makes no representations or warranties with respect to the contents or use of this
manual, and specifically disclaims any express or implied warranties of merchantability or
fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this
publication and to make changes to its content, at any time, without obligation to notify any
person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any NetWare
software, and specifically disclaims any express or implied warranties of merchantability or
fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to
any and all parts of NetWare software, at any time, without obligation to notify any person or
entity of such changes.
Trademarks
Novell, Inc., has made every effort to supply trademark information about company names,
products, and services mentioned in this book. Trademarks indicated below were derived
from various sources.
3Com, 3Com EtherLink, and EtherLink Plus are trademarks of 3Com Corporation.
AppleTalk is a registered trademark of Apple Computer, Inc.
IBM is a registered trademark of International Business Machines Corporation.
IBM PC AT/XT are trademarks of International Business Machines Corporation.
IBM Personal System/2 is a registered trademark of International Business Machines
Corporation.
Internetwork Packet Exchange (IPX) is a trademark of Novell, Inc.
LANtern is a trademark of Novell, Inc.
Micro Channel is a trademark of International Business Machines Corporation.
MS-DOS is a trademark of Microsoft Corporation.
NetWare and Novell are registered trademarks of Novell, Inc.
NetWire is a trademark of Novell, Inc.
Novell RX-Net is a trademark of Novell, Inc.
OS/2 is a registered trademark of International Business Machines Corporation.
Open Data-Link and ODI are trademarks of Novell, Inc.
PC-DOS is a trademark of International Business Machines Corporation.
Personal Computer AT and Personal Computer XT are trademarks of International Business
Machines Corporation.
Personal System/2 is a trademark of International Business Machines Corporation.
Token-Ring is a trademark of International Business Machines Corporation.
Windows is a trademark of Microsoft Corporation.
■ Copyright 1991 Novell, Inc. All rights reserved. No part of this
publication may be reproduced, photocopied, stored on a retrieval system, or
transmitted without the express prior written consent of the publisher.
Novell, Incorporated
122 East 1700 South
Provo, Utah 84606 USA
June 1991 Edition
Novell Part # 100-000871-002
User Comments
We are continually looking for ways to make our products and our manuals as easy
to use as possible. You can help us by sharing your comments and suggestions
about how our manuals could be made more useful to you and about any
inaccuracies or information gaps they may contain.
You can submit your comments either by filling out the ■User Comments■ form at
the end of this manual or by writing to us directly at the following address:
Novell, Inc.
Technical Publications
122 East 1700 South MS C-24-1
Provo, UT 84606 USA
We sincerely appreciate your comments about our products.Table of Contents
How to Use This Manual iii
About DOS ODI 1
Installing ODI for DOS 3
Before you begin 3
Create the master workstation diskette 4
Maintenance tips 6
NET.CFG Options 7
Link Driver drivername 9
Link Support 20
Protocol protocol_name 21
Appendix A: Using the NetWare IPX Shell with ODI23
Installation 23
Using NET.CFG 26
Appendix B: Using the Token-Ring Source Routing Driver29
Installing the source routing driver with DOS ODI30
Setting alternate parameters 31
Appendix C: System Messages 35
Index 61How to Use This Manual
This manual explains how to install Novell's Open Data-Link
Interface (ODI) for DOS. You may also need to consult the
documentation accompanying the protocols and drivers you are
using for product-specific information.
■About DOS ODI■ offers an overview of ODI's function.
■Installing ODI for DOS■ provides detailed information for
installing DOS ODI.
■NET.CFG Options■ contains configuration information for the
NET.CFG file.
■Appendix A: Using the NetWare IPX Shell with ODI■ explains
how to configure DOS ODI to connect to a NetWare server using
IPX and the NetWare shell.
■Appendix B: Using the Token-Ring Source Routing Driver■
explains how to install the Token-Ring Source Routing Driver
with DOS ODI.
■Appendix C: System Messages■ provides possible explanations
and corrections for system messages that you may encounter.
About DOS ODI
Open Data-Link Interface (ODI) adds functionality to network
computing environments by supporting multiple protocols and
multiple LAN adapters in a single workstation.
ODI creates a ■logical network board■ to allow multiple frame
formats over one network board and wire.
You can benefit from ODI in the following ways:
■ You can expand your network by using multiple protocols
(such as IPX/SPX, AppleTalk, LAT, or TCP/IP) without adding
network boards to the workstation.
■ You can communicate with a variety of workstations, file
servers, and mini and mainframe computers via different
protocol stacks without rebooting your workstation.
■ You can protect your LAN adapter investment, because all
protocols written to ODI specification can communicate
through any LAN adapter written to ODI specification.
■ You can spend less time and money on support. With one
LAN driver supporting multiple protocols, you have fewer
hardware components to support.
■ You can use the NET.CFG file to configure the LAN driver for
any possible hardware configuration.
You convert a standalone personal computer into a DOS ODI
network workstation by adding one or more network boards,
cabling, the DOS ODI workstation software, and protocol suite
software.
Three sets of files allow workstations to ■talk■ to each other, to the
file server, and to other hosts.
LSL.COM
LAN drivers
(MLIDs)
Protocol stacks
The Link Support Layer file enables
the workstation to communicate using
several protocols.
Driver files such as NE2000.COM
and TOKEN.COM communicate
directly with the LAN boards.
Drivers are also called MLIDs
(Multiple Link Interface Drivers).
Files such as IPXODI.COM and
TCPIP.EXE manage communications
among network stations.
You may need additional files specific to the networking product
you are using.
The following figure illustrates one configuration that would
benefit from using ODI. Because the LSL directs information to
the appropriate protocol stack, a user can use TCP/IP services as
well as IPX and AppleTalk services.
Installing ODI for DOS
This section explains how to install DOS ODI. You may also need
to consult the documentation accompanying the protocols and
drivers you are using for additional information.
IPX users should see ■Appendix A: Using the NetWare IPX Shell
with ODI■ of this manual. TCP/IP users should see the LAN
WorkPlace for DOS Administrator's Guide.
Before you begin
What you need
■ A working copy of the DOS ODI Workstation Services diskette
■ A ■disk■ (formatted diskette or hard disk) for each workstation
to boot from
1. Check the hardware and requirements.
Use any of the following computers as workstations:
■ IBM PC or compatible
■ IBM PC XT or compatible
■ IBM PC AT or compatible
■ IBM Personal System/2 (any model) or compatible
2. Make sure that the network board conforms to your cabling topology (such as
ARCnet, Token-Ring, or Ethernet) and that you have a DOS ODI LAN driver for
the board.
For a listing of drivers supplied by Novell, see the DOS ODI
Workstation Services diskette or the driver list on page 10. If an
appropriate driver is not provided by Novell, you must obtain one
from the board's vendor.
Create the master workstation diskette
The master workstation diskette contains copies of the files
necessary to boot one type of workstation. In this section, you will
copy files from the DOS ODI Workstation Services diskette to the
master workstation diskette.
Then you will either make a workstation boot diskette for each
workstation or copy the files from the master workstation diskette
to the hard disk from which a workstation boots.
1. Copy the workstation files from the DOS ODI Workstation Services diskette to
the master workstation diskette.
The following files are required to communicate with a server or
host:
■ LSL.COM
■ The LAN drivers for your network boards (NE2000.COM, for
example)
The following files are optional:
Note:The LANSUP.COM driver should be used on workstations using
the IBM LAN Support Program.
2. Put the filenames you need into a batch file on the master workstation diskette.
Load the LSL and then the LAN drivers. Your batch file should
look similar to the following:
LSL
NE1000
Note:If you are using a 3COM 3C503 board and want to use DIX
cabling, you must specify the DIX connector setting in the
NET.CFG file (see page 19) or at the command line when you load
the driver by entering a D, as follows:
3C503 D
BNC/TP, the default connector setting, does not require command
line information.
3. Create a NET.CFG file on the master workstation diskette (optional).
You must create a NET.CFG file if, for example, you have changed
hardware options on your network board or you are using multiple
protocols.
See the following section, ■NET.CFG Options,■ (on page 7) for
more information. You should also see the documentation specific
to your protocol.
4. Copy protocol suite files to the master workstation diskette or run the
necessary install utilities that came with your protocol suite.
Refer to the documentation specific to your protocol.
5. Use the master diskette to connect to the file server or host.
6. Create the workstation boot disk.
Copy the master workstation diskette files to each workstation
boot diskette or hard disk. From each workstation, connect to the
file server or host. Maintenance tips
1. If you cannot communicate on the network, check to see if
■ The network board is seated properly.
■ Board settings match the values displayed when you loaded
the LAN driver.
■ Board settings do not conflict with settings for other devices in
the machine.
■ The cable is connected properly.
■ All cabling is terminated properly.
■ The workstation node address does not conflict with any other
node address on the same physical network.
2. If you want information about a DOS ODI executable, type its name followed by
a question mark.
For example
NE2000 ? <Enter>
or
LSL.COM ? <Enter>
3. If you unload ODI drivers from memory, unload them in reverse order.
For example, if you work with two protocols that conflict when
both are running concurrently on the workstation or if you need to
free memory for large applications, unload the first set of files (in
reverse order) before you load the next set.
Unload the workstation files as follows:
PROTOCOL u <Enter>(for example, IPXODI u)
DRIVER u <Enter>(for example, NE2000 u)
LSL u <Enter>
If you do not unload the files in reverse order, you get an error
message similar to this: ■FATAL: There is a TSR above the loaded
NE1000.■
NET.CFG Options
The NET.CFG file is a configuration file that contains section
headings and options that deviate from the established defaults of
the ODI software. If you changed the default hardware settings
on the LAN adapter or if you are using multiple protocols, you
probably need a NET.CFG file.
You may also need to see the documentation specific to your
protocol for additional NET.CFG information.
Use any DOS text editor to create the file. Specify only options
that will change from the defaults.
Conventions
Main section headings must be left-justified and are not case
sensitive. The heading must precede the options you want to
include in that section. Options are not case sensitive and must
be preceded by a tab or hard spaces.
Precede comments with a semicolon (;). End each line with a hard
return. Write all numbers in decimal notation except where noted
otherwise.
The following are common main section headings in the NET.CFG
file:
■ Link driver
■ Link support
■ Protocol
Sample NET.CFG file
LINK DRIVER NE1000
; Change the interrupt (IRQ) to 5.
INT 5
; Change the port to 320 (hex)
PORT 320
The following sections contain an explanation of each option's
function and some possible reasons for changing the setting. In
the explanations, these conventions are used:
[ ] An optional element
number A decimal number
hex A hexadecimal number
The following chart lists the options defined by the DOS ODI
software. Other options may be available for the LAN driver or
protocol stack you are using. Refer to their documentation for
more information.
Main section headings are in white print and flush with the left
margin. Options are listed under each heading and indented.
Link Driver drivername
The following table outlines the NET.CFG options available to
LAN drivers on the DOS ODI Workstation Services diskette.
Square bullets (■) indicate options available to both ISA (industry
standard architecture) and MCA (microchannel architecture).
Options marked with an I are available to ISA only; options
marked with an M are available to MCA only.
Note:If you are using a LAN driver not listed above, refer to its
documentation for parameter applicability.
To use this heading, replace drivername with the name of the
driver you are using; the name is typically the LAN driver's
filename.
Replace drivername with one of the following driver names:
■ 3C501 (for 3COM EtherLink)
■ 3C503 (for 3Com EtherLink Series II)
■ 3C505 (for 3COM EtherLink Plus)
■ 3C523 (for 3Com EtherLink/MC)
■ EXOS (for Novell EXOS205 and EXOS215)
■ LANSUP (for the IBM LAN Support program only)
■ NE2 (for Novell Ethernet NE/2)
■ NE2-32 (for Novell Ethernet NE/2-32)
■ NE1000 (for Novell Ethernet NE1000)
■ NE2000 (for Novell Ethernet NE2000)
■ NE2100 (for Novell Ethernet NE2100)
■ PCN2L (for IBM PC Network II and II/A)
■ TOKEN (for IBM Token-Ring)
■ TRXNET (for Novell RX-Net and Turbo RX-Net)
After specifying a drivername, place both hardware commands
and software commands under the Link Driver heading.
You can specify options for each network board you are using, but
you must have a separate ■Link Driver drivername■ heading for
each network board. Hardware commands
DMA [#1 | #2] channel_number
This option specifies the hardware setting of the network board
used in the workstation. It allows DMA channels to be
configured.
Enter the channel number to be used. The default is the first
configurable channel, (#1).
You do not need to include the #1 option if you are using only the
default option. For example, if the first configurable DMA
channel on your board uses DMA channel 3, place the following
lines in your NET.CFG file:
Link Driver name
DMA 3
If, however, you are using the first and second DMA channels, you
do need to include the # sign for the second channel. For example,
if the first configurable DMA channel on your board will use
channel 3 and the second configurable channel will use channel 4,
place the following lines in your NET.CFG file:
Link Driver name
DMA 3
DMA #2 4
INT [#1 | #2] interrupt_request_number
This option specifies which interrupt the network board uses. Use
the interrupt request number set on the board.
The default is the first configurable interrupt line, (#1). Do not
include the #1 option if you are using only the default option.
For example, if the first configurable interrupt line on your board
will use IRQ 2, place the following lines in your NET.CFG file:
Link Driver name
Int 2
If your board can use two configurable interrupt lines and you
want to use both of them or only the second one, you must specify
the interrupt line (#1 or #2) to configure.
For example, if the first configurable interrupt line on your board
will use IRQ 2 and the second will use IRQ 3, place the following
lines in your NET.CFG file:
Link Driver name
Int 2
Int #2 3
The second INT channel requires you to use the pound sign (#).
MEM [#1 | #2] hex_starting_address [hex_length]
This option specifies a memory range to be used by the network
board.
Use the hexadecimal physical (absolute) address of the memory
used by the board. (This starting address must match the
starting address configured on the board.)
Enter the length (in hexadecimal paragraphs) of the memory
address range used by the board. A paragraph is 16 bytes.
For example, if you address a board from D0000 to D4000 (bytes),
the starting address is D0000 and the range is 400 (paragraphs).
In this case, place the following lines in your NET.CFG file:
Link Driver name
Mem D0000
Usually, the length is not needed.
PORT [#1 | #2] hex_starting_address [hex_number_of_ports]
Use this option to specify the starting port and number of ports in
the range. All values must be written in hexadecimal notation.
Use the starting hexadecimal I/O port number.
Use the hexadecimal number of ports in the range. If your
network board can use two ranges and you want to use either the
second range or both ranges, you must specify which range (#1 or
#2) to use.
For example, suppose you want to specify the starting port and
the number of ports in the first range on your board. The starting
I/O port is 300; 16 ports are in the first range. Place the following
lines in the NET.CFG file:
Link Driver name
Port 300
The number of ports is optional.
NODE ADDRESS hex_address
This option overrides any hard-coded node address in the network
board, if the hardware allows it. Use the hexadecimal address
number.
Changing the node address on a board can create conflicts
with other network boards. Use the hard-coded node
address whenever possible.
The example below shows how to change the node address on a
3C523 board:
Link Driver 3C523
Node Address 12D43
SLOT number
In slot-based machines, the driver usually locates the board by
scanning through the slots in order from lowest to highest. The
SLOT option directs the driver to eliminate the scan and locate
the board in the specified slot.
Use the number of the slot into which you inserted the board.
The slot number is usually found on the back of the computer.
The LAN driver will use the board in this slot.
For example, if you are using two NE/2 boards in the same
workstation and you insert one board into slot 1 and the other
into slot 2, place the following lines in your NET.CFG file:
Link Driver NE2
Link Driver NE2
Slot 2
Then place the following lines in your batch file:
LSL
NE2
NE2
The first NE/2 driver scans for an NE/2 board, finding the board
in slot 1. The second NE/2 driver, as directed by the SLOT option,
uses the NE/2 board in slot 2.Software commands
FRAME frame_type
This option enables the frame types used by the network board.
Use this option with boards that support multiple frame types.
For example, to enable the Ethernet II frame type on an NE1000
board, place the following lines in the NET.CFG file:
Link Driver NE1000
Frame ETHERNET_II
Usually, Ethernet LAN drivers default to the Ethernet_802.3
frame type; Token-Ring LAN drivers default to the Token-Ring
frame type.
The following chart lists the supported frame types for each LAN
driver supplied by Novell.
PROTOCOL name hex_protocol_ID frame_type
This option allows new network protocols to be handled by
existing LAN drivers.
Replace name with the name of the new protocol.
Replace hex_protocol_ID with the assigned hexadecimal protocol
ID that the protocol is assigned.
Replace frame_type with the frame type that the new protocol ID
applies to.
For example, if you want to use a new protocol XYZ with an NE2-
32 network board, the NET.CFG file would look similar to the
following:
Link Driver NE2-32
Frame ETHERNET_SNAP
Protocol XYZ 904A ETHERNET_SNAP
SAPS number
If you use the LANSUP driver, you may specify the number of
Service Access Points (SAPs) needed. Set the option to allow for
all applications using the IBM LAN Support Program. The
maximum value depends on the type of board used.
Default: 1
Note:This option is ignored if another application has already opened
the adapter before the LANSUP.COM driver was loaded.
LINK STATIONS number
If you use the LANSUP driver, you may specify the number of
link stations needed. Set the option to allow for all applications
using the IBM LAN Support Program. The maximum value
depends on the type of board used.
Default: 1
Note:This option is ignored if another application has already opened
the adapter before the LANSUP.COM driver was loaded.
ALTERNATE
Normally the LANSUP, Token, and PCN2L drivers use the
primary adapter. Use this option if you want the driver to use the
alternate adapter.
Specify ALTERNATE under the appropriate driver section
heading, as shown below:
Link Driver LANSUP
ALTERNATE
MAX FRAME SIZE number
This option sets the maximum number of bytes that can be put on
the wire by the LAN driver.
The TOKEN.COM driver's default size is 4216 bytes. But if your
board has 8 KB of shared RAM available, the default size is 2168
bytes.
The LANSUP.COM driver's default is normally 1144 bytes.
However, if you are using the IBM LAN Support Program with an
Ethernet device driver, the maximum size is 1496.
For TOKEN.COM and LANSUP.COM, the value for number must
be a multiple of 8. It must include the number of bytes for the
data packet, for adapter overhead (6 bytes), and for the largest
possible header (currently, 35 bytes LAN header + 5 bytes SNAP
header + 74 bytes protocol header = 114 bytes).
If the line speed is 16 Mbps, the value for number may be between
632 and 17,960. If the line speed is 4 Mbps, the value for number
must be between 632 and 4464.
If you wanted to use 2 KB data packets, the number would be
calculated as
2048 + 6 + 35 + 5 + 74 = 2168
then rounded up to the next multiple of 8: 2168.
The NET.CFG file would look similar to the following:
Link Driver TOKEN
MAX FRAME SIZE 2168
Note:When the driver loads, the sign-on message does not reflect the 6
bytes of overhead. Therefore, the MAX FRAME for the above
example would be displayed as 2162.
CONNECTOR DIX
This option configures the 3C503 LAN driver to use the DIX
(thick) connector. BNC/TP (thin) is the default.
DIX may also be selected at the command line, as in the following
example:
LSL
3C503 DLink Support
BUFFERS communication_number [size]
This option configures the number and size of receive buffers that
will be maintained by the LSL.
The number of communication buffers must be large enough to
hold all media headers and the maximum data size.
Default: 0
Refer to the documentation for the third-party protocol stacks for
possible settings.
Buffer size is optional. The minimum size is 618. The total buffer
space must fit into approximately 59 KB (number times size).
Default: 1130
MEMPOOL number[k]
Some protocols use this option to configure the size of the memory
pool buffers that the LSL will maintain.
The k notation means multiply by 1024.
Refer to the protocol documentation for settings.
Protocol protocol_name
BIND #board_number
Usually a protocol binds to the first network board it finds. The
BIND option forces the protocol to bind to the boards you specify.
Board numbers are displayed when you load the LAN drivers.
Replace board_number with logical boards you want the protocol
to bind to. For example, if you wanted protocol XYZ to bind to the
third logical board, the NET.CFG would look like this:
Protocol XYZ
Bind #3
To bind protocol XYZ to the second and third logical boards, the
NET.CFG would look like this:
Protocol XYZ
Bind #2, #3
Note:Some protocols do not support binding to multiple boards. Refer
to protocol documentation for binding information.
Notes:
Appendix A: Using the NetWare IPX Shell
with ODI
This chapter explains how to configure DOS ODI to connect to a
NetWare server using IPX and the NetWare shell. It highlights
the IPX-specific differences, exceptions, and additons to the
information in the first two sections of this manual. You need to
focus on the following areas:
■ Installation
■ Using NET.CFG
Installation
Follow the installation instructions in the ■Installing ODI for
DOS,■ section (page 3) using IPXODI as the protocol suite and
using the NetWare shell file.
1. Copy IPXODI.COM from the DOS ODI Workstation Services diskette to the
master workstation diskette.
2. Copy the shell file you will use from your NetWare release diskette to the
master workstation diskette.
(The x in NETx.COM refers to the DOS version that runs on your
workstations.)
3. Place IPXODI and then the shell file after the LAN drivers in the batch file you
created.
Your batch file should look similar to the following:
LSL
NE1000
IPXODI
NET3.COM
You can remove parts of IPXODI.COM to save memory.
The IPXODI.COM file actually contains three protocols:
■ IPX
■ SPX
■ Remote Diagnostics Responder
Since many applications do not need SPX or the Remote
Diagnostics Responder (required for third-party applications that
gather diagnostics information), workstations can save memory by
not loading these parts of the IPXODI.COM file.
Some NetWare utilities, such as RCONSOLE and NVER,
require SPX and the Remote Diagnostics Responder to be
loaded.
The chart below shows how to load IPXODI without the other two
parts of the file.
Note:If you will use remote boot with a DOS ODI workstation, follow
the remote boot instructions in your NetWare manual, with one
addition: include RPLODI.COM in the AUTOEXEC.BAT. The
RPLODI.COM file is located on the DOS ODI Workstation Services
diskette.
Use the following chart to locate remote boot instructions:
When you create the batch file, place RPLODI.COM after the LSL
but before the driver files, as shown below:
LSL.COM
RPLODI.COM
driver.COM
IPXODI
NET3
Using NET.CFG
When using the NET.CFG options with IPX and the NetWare
shell, you need the information contained in this section for the
following parameters:
■ Link Driver, PROTOCOL
■ Link Support, BUFFERS
■ Link Support, MEMPOOL
■ Protocol, BIND
Note:The SHELL.CFG file also contains NET.CFG network
configuration information. Any options from the SHELL.CFG file
can be specified in the more versatile NET.CFG file.
Use the chart below to determine whether to use both .CFG files
or to combine them into NET.CFG.
If a SHELL.CFG file exists and you place SHELL.CFG options in
the NET.CFG file, they will be ignored.
See your NetWare installation manual for SHELL.CFG options.
Link Driver, PROTOCOL
The PROTOCOL parameter assigns a board and frametype
combination. If you use a protocol in addition to protocol IPX, you
must explicitly include the protocol ID for IPX and for the
additional protocol. The NET.CFG would look like the following:
Link Driver NE2-32
Frame Ethernet_II
Frame Ethernet_802.3
Protocol IPX 0 Ethernet_802.3
Protocol ADD 1234 Ethernet_II
The following table lists the protocol IDs for frametypes available
with IPX.
Link Support, BUFFERS
The IPXODI protocol stack does not require the Link Support
Layer communication buffers.
Link Support, MEMPOOL
The IPXODI protocol stack does not require MEMPOOL buffers.
Protocol, BIND
If you do not specify a BIND parameter, IPXODI binds to the first
board it finds. If you are using multiple boards and frametypes,
you may want to specify a BIND parameter.
For example, if you wanted protocol IPXODI to bind to the third
logical board, the NET.CFG would look like this:
Protocol IPX
Bind #3
In a DOS environment, you can bind IPXODI.COM to only one
network board/frametype combination. Appendix B: Using the Token-Ring Source
Routing Driver
This appendix explains the use of the IBM Token-Ring Source
Routing Driver with DOS ODI.
The IBM Token-Ring Source Routing Driver enables
communication across IBM Token-Ring network bridges. Any type
of DOS ODI protocol stack can use this source routing feature to
communicate across IBM Token-Ring network bridges.
All nodes that need to communicate across a source route bridge
must be running the IBM Token-Ring Source Routing Driver.
The following figure shows an example network configuration
using IBM source routing bridges.
Installing the source routing driver with DOS ODI
To install source routing on workstations, complete the following
steps.
1. Copy the ROUTE.COM file from the DOS ODI Workstation Services diskette to
the boot disk.
The command to load ROUTE.COM should be added after
LANSUP.COM or TOKEN.COM, but before the protocol stack you
are using.
Note:If you are are using ROUTE.COM with remote boot, you must
load ROUTE.COM before the LAN driver in the AUTOEXEC.BAT.
See Appendix A for more information.
2. Set the parameters for ROUTE.COM.
The default parameters for ROUTE.COM can be used with most
network communications.
For additional ROUTE.COM parameters see ■Setting alternate
parameters■ on the next page. Add the parameters at the
command line.
Note:The ROUTE.COM module can be removed from memory by
specifying the u command line switch, as in the following example:
ROUTE U
Setting alternate parameters
The following parameters can be entered when ROUTE.COM is
first loaded.
BOARD = number MBR
CLEAR NODES = number
DEF REMOVE = number
GBR
The parameters can also be changed by loading ROUTE.COM a
second time. For online help, type
ROUTE ? <Enter>
Most of the parameters have default values that should work with
simple configurations for IBM bridges. If you have installed
parallel IBM bridges, you can change some of the parameters to
reduce traffic on some of the paths. Each parameter is described
below.
A sample ROUTE file is included on page 34.
BOARD = number
Use this parameter to specify a board number for the network
board.
■ If this parameter is not specified, the default of 1 is used.
■ If you have loaded more than one LAN driver in the
workstation, the board number is determined by the order in
which the LAN drivers are loaded (the first board is 1). See
your batch file for the order you have specified.
■ Load ROUTE for each logical board number (frame type)
enabled by the Token-Ring LAN driver.
CLEAR
Use this parameter to manually clear the Source Routing table
and force a dynamic rebuilding of the table by sending a default
frame to each node in the network. Use this parameter when an
IBM bridge on the network has gone down and an alternate route
is available.
DEF
Use this parameter to prevent frames that have unknown
(DEFault) destination addresses from being sent across Single
Route IBM bridges.
■ If this parameter is specified, all frames that have addresses
not in the workstation's Source Routing table are forwarded as
All Routes Broadcast frames.
■ If this parameter is not specified, all frames that have
addresses not in the workstation's Source Routing table are
forwarded as Single Route Broadcast frames.
■ If ROUTE.COM has already been loaded with the DEF
parameter, reloading ROUTE.COM with this parameter
broadcasts all subsequent Single Route Broadcast frames as
All Routes Broadcast frames.
GBR
Use this parameter to specify that all General BRoadcast frames
are to be sent as All Routes Broadcast frames.
■ If this parameter is not specified when ROUTE is loaded, all
General Broadcast frames are broadcast as Single Route
Broadcast frames.
■ If ROUTE has already been loaded with the GBR parameter,
reloading ROUTE with this parameter broadcasts all
subsequent General Broadcast frames as All Routes Broadcast
frames.
MBR
Use this parameter to specify that all Multicast BRoadcast frames
are to be sent as All Routes Broadcast frames.
■ If the parameter is not specified when ROUTE is loaded, all
Multicast Broadcast frames are broadcast as Single Route
Broadcast frames.
■ If ROUTE has already been loaded with the MBR parameter,
reloading ROUTE with this parameter broadcasts all
subsequent Multicast Broadcast frames as All Routes
Broadcast frames.
NODES = number
Use this parameter to specify the number of table entries in the
Source Routing table. This parameter must be entered the first
time ROUTE.COM is loaded. The parameter cannot be changed
by reloading ROUTE.COM.
Replace number with a value from 8 to 255. The default is 16.
REMOVE = number
Use this parameter to remove a specified node address from the
workstation's Source Routing table. Use the parameter when a
bridge has gone down. Removing the node from the Source
Routing table forces the workstation to determine an alternate
path.
Replace number with a 12-digit (6-byte) hexadecimal number. If
fewer than 9 digits are entered, ROUTE.COM prefixes the address
with 4000h. For example, REMOVE=2 is interpreted as
REMOVE=400000000002.
Sample ROUTE.COM
The following command shows one possible ROUTE setting:
ROUTE BOARD=3, DEF, GBR, MBR
If you set these parameters, ROUTE.COM would do the following:
■ Send packets through logical board 3
■ Send all frames that are not addressed in the workstation's
source routing table as All Routes Broadcast
■ Send General Broadcast frames as All Routes Broadcast
■ Send Multicast Broadcast frames as All Routes Broadcast
When the NODES parameter is not set, ROUTE assumes the
default of 16.
The CLEAR and REMOVE parameters are not needed for the
initial load of ROUTE.COM. However, if a bridge goes down, you
can reload ROUTE with these parameters to reconfigure the
Source Routing table.
Note:For more information on using source routing, see the IBM Token-
Ring Network Architecture Reference manual.
Appendix C: System Messages
Connector is BNC/TP (Thin).
Source: 3C503.COM
Explanation: The connector selected for the board is for Thin Ethernet
cabling.
Action: None.
Connector is DIX (Thick).
Source: 3C503.COM
Explanation: The connector selected for the board is for Thick Ethernet
cabling.
Action: None.
FATAL: 3C501 -Card not found.
Source: 3C501.COM
Explanation: The 3C501 card did not respond to a reset command by
the 3C501.COM driver at the specified I/O port settings.
Action: Make sure a 3C501 board is installed. Verify the hardware
jumper settings. If the settings do not match the defaults, specify the
settings in the NET.CFG file.
FATAL: 3C503 -Card not found.
Source: 3C503.COM
Explanation: The 3C503.COM driver could not locate a 3C503 board at
the specified hardware settings.
Action: Make sure a 3C503 board is installed. Verify the hardware
jumper settings. If the settings do not match the defaults, specify the
settings in the NET.CFG file.
FATAL: 3C503 -Card will not initialize.
Source: 3C503.COM
Explanation: A hardware failure occurred.
Action: Check for hardware settings that conflict with other installed
boards.
FATAL: 3C503 -Interrupt is invalid (2, 3, 4, 5, and 9 valid).
Source: 3C503.COM
Explanation: An invalid interrupt was selected in the NET.CFG file.
Action: Correct the NET.CFG entry with a valid interrupt.
FATAL: 80186 Failed to Reset Properly.
Source: EXOS.COM
Explanation: The 80186 on the EXOS 205/215 board failed to function
properly.
Action: Try a different slot. If the error persists, replace the board.
FATAL: 82586 Failed in IA Setup.
Source: EXOS.COM
Explanation: The 82586 on the EXOS 205/215 board could not set the
individual node address.
Action: Try a different slot. If the error persists, replace the board.
FATAL: 82586 Failed to Configure Properly.
Source: EXOS.COM
Explanation: The 82586 on the EXOS 205/215 board failed to configure
itself properly.
Action: Try a different slot. If the error persists, replace the board.
FATAL: 82586 Failed to Diagnose Command.
Source: EXOS.COM
Explanation: The 82586 on the EXOS 205/215 board failed its self-
diagnostics routines.
Action: Try a different slot. If the error persists, replace the board.
FATAL: 82586 Failed to Reset Properly.
Source: EXOS.COM
Explanation: The 82586 on the EXOS 205/215 board failed to initialize.
Action: Try a different slot. If the error persists, replace the board.
FATAL: 82586 Failed to Start RU Properly.
Source: EXOS.COM
Explanation: The 82586 on the EXOS 205/215 board was unsuccessful
in getting the receive unit to start.
Action: Try a different slot. If the error persists, replace the board.
FATAL: An Interrupt Failed to Occur During Dir.Open.Adapter.
Source: TOKEN.COM
Explanation: After the Dir.Open.Adapter command was given, the
adapter failed to respond.
Action: Try a different slot. If the error persists, replace the adapter.
FATAL: Board failed to initialize correctly.
Source: MLID
Explanation: The MLID could not initialize its board correctly. A
hardware failure usually prevents initialization.
Action: Refer to the MLID documentation for a description of the error.
FATAL: Bring Up Error After Call to DIR.Initialize = xx.
Source: TOKEN.COM
Explanation: DIR.Initialize has returned a value for the bring-up
diagnostics result code of xx.
Action: For the description of the actual error, refer to the interface
chapter of the IBM Local Area Network Technical Reference.
FATAL: Could not find a board that supports IPX (See PROTOCOL
keyword).
Source: IPXODI
Explanation: IPX could not find a board to bind with. For IPX to bind,
it must have a protocol ID registered with the Link Support Layer. Most
MLIDs will register an IPX Protocol ID by default. However, if you have
specified the PROTOCOL keyword under an MLID's section heading in
the NET.CFG file, this error may be generated. When a protocol ID has
been specified for another protocol stack, the MLID does not register a
default protocol ID for IPX.
Action: Register a protocol ID for IPX along with the other Protocol IDs
you are registering. Refer the chart on page 27 for a listing of IPX
protocol ID numbers.
FATAL: Could not find an enabled 3C523 adapter in any slot.
Source: 3C523.COM
Explanation: By default, the 3C523.COM driver scans the PS/2 slots to
find the 3C523 board it should use. The driver starts scanning at slot 1.
The driver could not find a 3C523 in any slot.
Action: Make sure that the 3C523 board is firmly seated in the slot.
FATAL: Could not find an NE2 adapter in any slot.
Source: NE2.COM
Explanation: By default, the NE2.COM driver scans the PS/2 slots to
find the NE2 board it should use. The driver starts scanning at slot 1.
The driver could not find an NE2 in any slot.
Action: Make sure the NE2 board is firmly seated in the machine's slot.FATAL: Could not find an NE2-32 adapter in any slot.
Source: NE2-32.COM
Explanation: By default, the NE2-32.COM driver scans the PS/2 slots to
find the NE2-32 board it should use. The driver starts scanning at slot 1.
The driver could not find an NE2-32 in any slot.
Action: Make sure the NE2-32 board is firmly seated in the slot.
FATAL: Could not find <name> MLID to unload.
Source: MLID
Explanation: A request was made to unload the MLID, but the MLID is
not loaded.
Action: None.
FATAL: Different IPX or an IPX interrupt has been hooked.
Source: IPXODI
Explanation: You tried to unload the IPX from memory, but IPX
detected a condition that would not allow it to be removed safely. This
can occur for two reasons:
■ The resident IPXODI and the IPXODI used to unload the resident
IPXODI are not the same version.
■ Another program has been loaded that has hooked one of IPXODI's
interrupt vectors. IPXODI uses the following interrupt vectors: INT
08h, INT 2Fh, INT 64h, and INT 7Ah.
Action: Complete one of the following:
■ Use the same version of IPXODI to unload IPX as you used to load
it.
■ Unload the program that has hooked to one or more IPX interrupt
vectors and then unload IPXODI.
FATAL: Different LSL or a LSL interrupt has been hooked.
Source: LSL
Explanation: You tried to unload the LSL from memory, but it detected
a condition that would not allow it to be removed safely. This can occur
for two reasons:
■ The resident LSL and the LSL used to unload the resident LSL are
not the same version.
■ Another program has been loaded that has hooked one of the LSL's
interrupt vectors. The LSL uses the following interrupt vectors: INT
08h and INT 2Fh.
Action: Complete one of the following:
■ Use the same version to unload LSL as you used to load it.
■ Unload the program that has hooked to the LSL's interrupt vectors
before unloading the LSL.
FATAL: Direct Station 0 already in use by another application.
Source: LANSUP.COM
Explanation: The LANSUP.COM driver uses Direct Station 0. Only
one application running on the IBM LAN Support program can use Direct
Station 0.
Action: Unload the other application.
FATAL: Dir.Open.Adapter Failed to Respond Properly.
Source: TOKEN.COM
Explanation: After receiving false completions and trying several times
to get the card to respond to the Dir.Open.Adapter command, the driver
has given up.
Action: Try a different slot. If the error persists, replace the card.
FATAL: Dir.Open.Adapter:-Lobe Media...
-Physical Insertion...
-Addr. Verification...
-Ring Poll...
-Request Parameters...
Action: Refer to the ■Token-Ring Network Adapter Open errors for all
CCBS■ section in Appendix B of the IBM Local Area Network Technical
Reference.
FATAL: Dir.Open.Adapter: Returned Error Code = xx.
Source: TOKEN.COM
Explanation: The Dir.Open.Adapter call has returned an error code.
Action: The driver will try again. The definition of the error code is in
the interface chapter of the IBM Local Area Network Technical Reference.
FATAL: Error initializing board.
Source: LANSUP.COM
Explanation: The LAN Support Program could not initialize the
network board.
Action: Check the installation of the LAN Support software.
FATAL: Error opening board.
Source: LANSUP.COM
Explanation: The LAN Support Program could not open the network
board.
Action: Check the installation of the LAN Support software.
FATAL: Error shutting down <name> MLID, unload operation aborted.
Source: MLID
Explanation: The MLID was trying to remove the resident MLID from
memory. The MLID could not successfully shut down the resident MLID.
A hardware failure has probably occurred.
Action: Run diagnostics on the network board and workstation. Replace
the faulty hardware.
FATAL: EXOS 215 Card Not Found.
Source: EXOS.COM
Explanation: The EXOS.COM driver scans by default through all the
slots starting at slot 1. Either the EXOS 215 board was not present in
the slot designated by the NET.CFG file, or the driver could not find the
board at all.
Action: Verify the EXOS 215 card is installed and the slot number is
described correctly by the NET.CFG if the file is present.
FATAL: EXOS Card Memory Failure.
Source: EXOS.COM
Explanation: The EXOS 205/215 has not passed the memory test.
Action: If the card's jumper settings are not the defaults, verify that
they match the NET.CFG file's settings. If the settings match, try a
different slot. If the error persists, replace the board.
FATAL: Failed to locate MLID Section Heading in NET.CFG file.
Source: MLID
Explanation: You tried to load the MLID again. Normally you would do
this so that you could use two or more boards in the workstation. When
two or more of the same type of network board are installed in the
workstation, you must specify an associated MLID section heading in the
NET.CFG file. An entry in the NET.CFG file for two boards would look
similar to the following:
;Allow the first one to use default values.
LINK DRIVER NE1000
;This section is for the second board.
LINK DRIVER NE1000
INT 4
PORT 320
Action: Add the commands for both MLID boards to the NET.CFG file.
Then reboot the workstation.
FATAL: IBM LAN Support Program has not been loaded.
Source: LANSUP.COM
Explanation: The LANSUP.COM driver requires that the IBM LAN
Support Program be loaded.
Action: Install the LAN Support Software using the IBM-supplied
DXMAID utility and retry the operation.
FATAL: Init586: Configure command failed.
Source: 3C523.COM
Explanation: A hardware failure has occurred.
Action: Install the 3C523 board in a different slot. If the driver still
fails to load, the 3C523 board is probably bad and should be replaced.
FATAL: Init586: IA_Setup command failed.
Source: 3C523.COM
Explanation: A 3C523 hardware failure has occurred.
Action: Install the 3C523 in a different slot. If the driver still fails to
load, the 3C523 board is probably bad and should be replaced.
FATAL: Init586: Initial communication with 82586 failed.
Source: 3C523.COM
Explanation: A hardware failure has occurred.
Action: Install the 3C523 board in a different slot. If the driver still
fails to load, the 3C523 board is probably bad and should be replaced.
FATAL: Invalid base memory address - Must be C0000 or D0000.
Source: NE2-32.COM
Explanation: Because the NE2-32 board is a true 32-bit board, it can
have its base memory located above the 1MB real mode memory limit.
Since DOS ODI is executing in real mode, the NE2-32.COM driver cannot
access the board's RAM when it is located above the 1MB address range.
Action: Use the IBM Reference diskette to change the board's base
memory setting to either C0000 or D0000.
FATAL: Invalid Ethernet node address specified.
Source: MLID
Explanation: You used the NODE ADDRESS option in the NET.CFG
file to override the node address on the network board. The number
specified was not a valid Ethernet node address. An Ethernet address is
6 bytes long.
This error occurs if Bit 0 of the first address byte is a 1. This bit must
always be 0. For example, if the first byte has the following address, an
invalid Ethernet address is generated.
First Byte
7 6 5 4 3 2 1 0
┌─┬─┬─┬─┬─┬─┬─┬─┐
│0│0│0│0│0│0│0│1│
└─┴─┴─┴─┴─┴─┴─┴─┘
Action: Change the NET.CFG file so that a valid node address is
specified.
FATAL: Invalid parameter.
Source: IPXODI
Explanation: When you tried to load IPXODI, you specified an invalid
parameter on the command line. IPXODI was not loaded. The only valid
parameters are ? for information, U for unload, D to load IPX and SPX
only, and A to load IPX only.
Action: Specify a valid parameter.
or
Source: LSL
Explanation: When you tried to load the LSL, you specified an invalid
parameter on the command line. The LSL was not loaded. The only
valid parameters are ? for help and U for unload.
Action: Specify a valid parameter.
FATAL: Invalid Token-Ring node address specified.
Source: MLID
Explanation: You used the NODE ADDRESS option in the NET.CFG
file to override the node address on the network board. The number
specified was not a valid Token-Ring node address. A Token-Ring
address is 6 bytes long. This error occurs if Bit 7 of the first address byte
is a 1. This bit should always be a 0. For example, if the first byte has
the following address, an invalid Token-Ring address is generated.
First Byte
7 6 5 4 3 2 1 0
┌─┬─┬─┬─┬─┬─┬─┬─┐
│1│0│0│0│0│0│0│0│
└─┴─┴─┴─┴─┴─┴─┴─┘
Action: Change the NET.CFG file so that a valid node address is
specified.
FATAL: IPX already loaded.
Source: IPXODI
Explanation: IPX has already been loaded. It needs to be loaded only
once.
Action: None.
FATAL: IPX is already registered with the LSL.
Source: IPXODI
Explanation: IPX was not removed from the LSL's register when it was
unloaded. The system may be corrupted.
Action: Reboot the workstation.
FATAL: IPX is not loaded.
Source: IPXODI
Explanation: You tried to unload IPX, but it has not been loaded.
Action: None.
FATAL: Loading MLID again requires configuration information in
NET.CFG.
Source: MLID
Explanation: You tried to load the MLID a second time. Normally you
would do this so that you could use two or more boards in the
workstation. When two or more of the same type of network board are
installed in the workstation, you must specify an associated MLID section
heading in the NET.CFG file.
An entry in the NET.CFG file for two boards would look similar to the
following:
;Allow the first one to use default values.
LINK DRIVER NE1000
;This section is for the second board.
LINK DRIVER NE1000
INT 4
PORT 320
Action: Create a NET.CFG file and add the commands for both MLID
boards to the file. Then reboot the workstation.
FATAL: LSL already loaded.
Source: LSL
Explanation: The LSL has already been loaded. It can be loaded only
once.
Action: None.
FATAL: LSL is not loaded.
Source: LSL
Explanation: You tried to unload the LSL, but it is not loaded.
Action: None.
FATAL: Multiplex interrupt 2Fh has no free slots.
Source: LSL
Explanation: The LSL could not find a free slot for use with INT 2F
(Hex). When your computer is first booted, approximately 63 multiplex
slots are available. All available slots are already being used by
applications.
Action: Unload an application that is using an INT 2F multiplex
interrupt; then load the LSL.
FATAL: NE2 NIC command port failed to respond.
Source: NE2.COM
Explanation: The installed NE2 board has malfunctioned.
Action: Replace the board.
FATAL: NE2 NIC RAM failure.
Source: NE2.COM
Explanation: The NE2 board's installed on-board memory has
malfunctioned.
Action: Replace the board.
FATAL: NE2-32 NIC command port failed to respond.
Source: NE2-32.COM
Explanation: The installed NE2-32 board has malfunctioned.
Action: Replace the board.
FATAL: NE2-32 NIC RAM failure.
Source: NE2-32.COM
Explanation: The installed NE2-32 board's on-board memory has
malfunctioned.
Action: Replace the board.
FATAL: NE1000 NIC command port failed to respond.
Source: NE1000.COM
Explanation: The NE1000 board has malfunctioned, is not installed, or
is not configured to the same port as selected for the driver.
Action: Complete one or more of the following:
■ Make sure that an NE1000 board has been installed and configured.
■ Make sure that the configuration for the NE1000 board matches the
configuration for the NE1000 driver. Configuration options other
than the defaults must be entered in the NET.CFG file.
■ Replace the board.
FATAL: NE1000 NIC RAM failure.
Source: NE1000.COM
Explanation: The NE1000 board's on-board memory has malfunctioned.
Action: Replace the board.
FATAL: NE2000 NIC command port failed to respond.
Source: NE2000.COM
Explanation: The NE2000 board has malfunctioned, is not installed, or
is not configured to the same port as selected for the driver.
Action: Complete one or more of the following:
■ Make sure that an NE2000 board has been installed and configured.
■ Make sure that the configuration for the NE2000 board matches the
configuration for the NE2000 driver. Configuration options other
than the defaults must be entered in the NET.CFG file.
■ Replace the board.
FATAL: NE2000 NIC is NOT supported in a 8-bit slot.
Source: NE2000.COM
Explanation: The NE2000 board is located in an 8-bit slot in the
machine. The NE2000.COM driver supports the NE2000 only in a 16-bit
AT bus slot.
Action: Place the NE2000 board in a 16-bit slot and try again.
FATAL: NE2000 NIC RAM failure.
Source: NE2000.COM
Explanation: The NE2000 board's on-board memory has malfunctioned.
Action: Replace the board.
FATAL: NE2000 NIC was not found at specified hardware settings.
Source: NE2000.COM
Explanation: The NE2000.COM driver found a board at the specified
hardware settings, but the board is not an NE2000 board.
Action: Check the installed hardware.
FATAL: No more room in the LSL for another protocol stack.
Source: IPXODI
Explanation: The maximum number of protocol stacks has been
registered with the LSL. The DOS ODI LSL can support up to eight
protocol stacks.
Action: Remove an existing protocol stack.
FATAL: No room in LSL for board using FRAME <string>.
Source: MLID
Explanation: The maximum number of boards, whether virtual or
physical, has been registered with the LSL. The DOS ODI LSL can
support up to eight boards.
Action: Reduce the number of active boards in the system by unloading
a board or by decreasing the number of frame types activated by the
MLID.
FATAL: RXNet command port failed to respond.
Source: TRXNET.COM
Explanation: The TRXNET.COM driver could not find an RX-Net board
in the workstation.
Action: Make sure an RX-Net board is installed in the workstation and
is firmly seated. Make sure that the values for the hardware settings in
the driver (the default or the values set in the NET.CFG file) match the
values set on the board.
FATAL: RXNet RAM failure.
Source: TRXNET.COM
Explanation: The RX-Net board's RAM has failed the RAM test.
Action: Replace the board.
FATAL: Specified slot contains an NE2 but it is not enabled.
Source: NE2.COM
Explanation: The located NE2 board was not enabled. It has probably
malfunctioned.
Action: Replace the board.
FATAL: Specified slot contains an NE2-32 but it is not enabled.
Source: NE2-32.COM
Explanation: The located NE2-32 board was not enabled. It has
probably malfunctioned.
Action: Replace the board.
FATAL: Specified slot does not contain an enabled 3C523 adapter.
Source: 3C523.COM
Explanation: A SLOT number option was specified in the NET.CFG file.
The specified slot does not contain a 3C523 board. Note that slot
numbers are 1 based and correspond to the slot numbers on the back of
the computer.
Action: Modify the NET.CFG to specify the correct number.
FATAL: Specified slot does not contain an NE2 adapter.
Source: NE2.COM
Explanation: A SLOT number option was specified in the NET.CFG file.
The specified slot does not contain an NE2 board. Note that slot numbers
are 1 based and correspond to the slot numbers on the back of the
computer.
Action: Modify the NET.CFG file to specify the correct slot number.
FATAL: Specified slot does not contain an NE2-32 adapter.
Source: NE2-32.COM
Explanation: A SLOT number option was specified in the NET.CFG,
but the specified slot does not contain an NE2-32 board. Slot numbers
are 1 based and correspond to the slot numbers on the back of the
computer.
Action: Modify the NET.CFG file to specify the correct slot number.
FATAL: The LSL is not loaded.
Source: IPXODI
Explanation: IPX requires that the LSL be loaded first.
Action: Load LSL.COM; then load IPXODI.COM.
or
Source: MLID
Explanation: The LSL must be loaded before an MLID can be loaded.
Action: Load LSL.COM; then load the MLID.
FATAL: There is a TSR above the loaded IPX.
Source: IPXODI
Explanation: You tried to unload IPX from memory, but IPX detected
another terminate-and-stay-resident program loaded above IPX. For IPX
to unload safely, TSRs that were loaded after it must be unloaded first.
Action: Either load the TSR before loading IPX or unload the TSR
before trying this operation.
FATAL: There is a TSR above the loaded LSL.
Source: LSL
Explanation: You tried to unload the LSL from memory, but the LSL
detected another terminate-and-stay-resident program loaded above the
LSL. For the LSL to unload safely, TSRs that have been loaded after it
must be unloaded first.
Action: Either load the other TSR before loading the LSL or unload the
TSR before trying this operation.
FATAL: There is a TSR above the loaded <name> MLID.
Source: MLID
Explanation: You tried to unload the MLID from memory, but the
MLID detected another terminate-and-stay-resident program loaded
above the MLID. For the MLID to safely unload, TSRs that were loaded
after it must be unloaded first.
Action: Either load the other TSR before loading the MLID or unload
the TSR before trying this operation.
FATAL: This old LSL is not supported.
Source: IPXODI
Explanation: IPXODI cannot run correctly using this version of the
LSL.
Action: Update your LSL.COM to a newer version.
or
Source: MLID
Explanation: The MLID cannot run correctly using this version of the
LSL.
Action: Update your LSL.COM to a newer version.
FATAL: Token-Ring Adapter Not Found at Designated Slot/IO Port.
Source: TOKEN.COM
Explanation: The TOKEN.COM driver by default scans each slot on a
microchannel machine. If a Token-Ring card is located, the I/O port
address is checked to determine if the correct board has been found.
Either the Token-Ring card is not present or the NET.CFG does not
reflect the POS register settings.
Action: Verify that the Token-Ring card is installed. Verify that the
NET.CFG and the POS registers correctly describe the desired
configuration.
FATAL: Token-Ring Buffer Memory Failure.
Source: TOKEN.COM
Explanation: The TOKEN.COM card has failed the shared RAM
memory test by the driver.
Action: Try a different slot. If the error persists, replace the board.
FATAL: Token-Ring Hardware Failed to Respond After Retry.
Source: TOKEN.COM
Explanation: The TOKEN.COM driver has tried twice to initialize the
Token-Ring card and failed.
Action: Try a different slot. If the error persists, replace the board.
FATAL: Token-Ring Hardware failure during card initialize.
Source: TOKEN.COM
Explanation: The TOKEN.COM driver waited for the card to complete
its internal diagnostics and produce an interrupt, but the card has not
responded.
Action: Try a different slot. If the error persists, replace the board.
FATAL: Token-Ring Shared RAM is on Incorrect Boundary.
Source: TOKEN.COM
Explanation: The TOKEN.COM driver has found the base address for
shared RAM is not on a 16K boundary.
Action: Verify that the addresses given in the NET.CFG file do not
conflict and that they match the jumper (ISA) or POS (MCA) settings.
FATAL: Token-Ring Signature Hardware Failure.
Source: TOKEN.COM
Explanation: The TOKEN.COM card failed the signature test.
Action: Verify that the Token-Ring card is installed and that the
settings in the NET.CFG match the jumper settings (ISA) or that POS
register values (MCA) are correct.
FATAL: Token-Ring ROM/MMIO Domain and Shared RAM Overlap.
Source: TOKEN.COM
Explanation: The base address settings for the shared RAM and the
ROM/MMIO are too close and overlap.
Action: Change the base address settings for the shared RAM or the
ROM/MMIO.
FATAL: Work Area Exceeded, reduce number of SAPs and/or Link
Stations.
Source: LANSUP.COM
Explanation: The number of SAPs or Link Stations specified in the
NET.CFG file exceed the number of SAPs or Link Stations that the
network board can handle.
Action: Modify the number of SAPs or Link Stations specified in the
NET.CFG file.
Inserting into ring...Please wait
Source: TOKEN.COM
Explanation: The Token-Ring card is trying to insert into the Token-
Ring.
Action: None.
IPX protocol bound to <name> MLID Board # <number>.
Source: IPXODI
Explanation: This message is displayed after IPX has loaded
successfully. It is not a error message but simply tells you which logical
MLID IPX is using.
<name> The MLID's short name (NE1000, for example).
<number> The logical board number of the MLID. This number
is 1based (for example, the first MLID is assigned
board #1).
Action: None.
IPX protocol successfully removed.
Source: IPXODI
Explanation: A request was made to unload IPXODI, and IPXODI was
removed from memory.
Action: None.
LSL successfully removed.
Source: LSL
Explanation: A request was made to unload the LSL, and the LSL was
removed from memory.
Action: None.
<name> MLID successfully removed.
Source: MLID
Explanation: A request was made to unload an MLID, and the MLID
was removed from memory.
Action: None.
Number of buffers <number1>, Buffer size <size> bytes, Memory pool
<number2> bytes
Source: LSL
Explanation: This information appears when the LSL has read
configuration information from the NET.CFG file. (The LSL does not
display default values when it loads.)
<number1> The number of communication buffers allocated by
the LSL. Normally, the LSL does not need buffers;
therefore, none should be allocated unless directed by
a protocol's documentation. This number may be less
than requested due to memory limits in the LSL.
<size> The size of the LSL's communications buffers (106
bytes are reserved for protocol and media headers).
This value cannot be smaller than 618 bytes.
<number2> The amount of memory allocated to the LSL's free
memory pool. This free memory pool is used by
protocols. This value may be smaller than requested
due to memory limits within the LSL. The LSL first
allocates the requested number of communications
buffers and then allocates the free memory pool from
the remaining memory. Normally, a free memory
pool is not needed and should not be allocated, unless
directed by a protocol's documentation.
Action: None.
Programmed I/O Mode Selected.
Source: 3C503.COM
Explanation: The adapter is jumpered with the shared RAM disabled.
The driver and adapter support either shared RAM or programmed I/O.
Action: To configure the adapter for shared RAM mode, change the
jumpers to the appropriate settings for the base-shared RAM address.
Trying again...Dir.Open.Adapter Return Code = xx.
Source: TOKEN.COM
Explanation: The Dir.Open.Adapter call has returned an error code.
Action: The driver will try again. The definition of the error code is in
the interface chapter of the IBM Local Area Network Technical Reference.
WARNING: 3C503 DMA Mode not Supported
Source: 3C503.COM
Explanation: The 3C503.COM supports only programmed I/O or shared
RAM modes. The NET.CFG contains a DMA entry. The driver issues
this warning and ignores the setting.
Action: DMA is not supported with this driver. Use either programmed
I/O or shared RAM mode. Shared RAM mode is faster.
WARNING: 3C503 NET.CFG Specified Shared RAM Address--NIC
Configured PIO.
Source: 3C503.COM
Explanation: The 3C503 adapter is shipped with the shared RAM
memory disabled. The NET.CFG file has specified a shared RAM
address, and the adapter is jumpered with memory disabled. This is not
fatal, however; the driver supports both shared RAM and programmed
I/O (PIO) modes. The driver will use PIO mode without modification.
Action: Set the jumper on the adapter to the appropriate address if you
want shared RAM mode. Shared RAM mode is faster than PIO or DMA
modes. The 3C503.COM driver supports only shared RAM and PIO
modes.
WARNING: Byte value greater than 255 was truncated
Source: IPXODI
Explanation: An IPX or SPX parameter specified in the NET.CFG or
SHELL.CFG file was set to a value greater than 255. The value used will
be 255 (the maximum configurable value).
Action: Change the NET.CFG file so that the IPX or SPX parameter is
valid.
WARNING: Error registering Protocol=<name>, PID=<number>,
Frame=<type>
Source: MLID
Explanation: The MLID could not register the specified Protocol ID.
<name> The name of the protocol.
<number> The value of the Protocol ID used to register the
Protocol ID.
<type> The frame type for which the Protocol ID was
registered.
Action: Verify the protocol information in the NET.CFG file.
WARNING: Frame type is already activated--duplicate entry ignored.
Source: MLID
Explanation: Two FRAME keywords under the same main section
heading specified the same frame type. A specific frame type can be
specified only once per driver.
Action: Remove the duplicate entry.
WARNING: Max Frame Size is too Large in NET.CFG. Max = 17960.
Source: TOKEN.COM
Explanation: The NET.CFG file has defined the maximum frame size to
be larger than the maximum allowed value.
Action: Adjust the NET.CFG entry. The driver will use the maximum
value until the correction is made.
WARNING: Max Frame Size is too Small in NET.CFG. Min = 632.
Source: TOKEN.COM
Explanation: The NET.CFG file has defined the minimum frame size to
be smaller than the minimum allowed value.
Action: Adjust the NET.CFG entry. The driver will use the minumum
value until the correction is made.
WARNING: MLID does not support Frame <type> - Protocol keyword
ignored.
Source: MLID
Explanation: The PROTOCOL option was specified in the NET.CFG for
an MLID. The specified frame type is not supported by the MLID.
Action: Check the PROTOCOL line in the NET.CFG file for omissions of
required dashes and underscores or misspellings. Check the MLID
documentation for supported frame types.
WARNING: NET.CFG ignored - MLID name cannot be more than 8
characters long.
Source: IPXODI
Explanation: The Bind MLID option in the NET.CFG file specified an
MLID with a name longer than 8 characters.
Action: Refer to the MLID's documentation for more information on the
name.
WARNING: Node Address override not supported. Specify override
when loading IBM LAN Support Software.
Source: LANSUP.COM
Explanation: A node address was specified in the NET.CFG file for the
LANSUP.COM driver. The node override must be specified when loading
the IBM LAN Support software.
Action: Refer to the IBM LAN Support documentation for instructions.
WARNING: Protocol keyword must have a frame type - entry ignored.
Source: MLID
Explanation: The PROTOCOL option was specified in the NET.CFG for
an MLID. The entry failed to specify the associated frame type for the
protocol ID addition. An entry in the NET.CFG file for the PROTOCOL
option should look similar to the following:
LINK DRIVER NE1000
PROTOCOL IPX 8137 ETHERNET_II
Action: Specify a frame type with the PROTOCOL option.Index
A
ALTERNATE (NET.CFG) 17
B
Batch file, creating for master
workstation diskette 5
BIND (NET.CFG) 21
BOARD (ROUTE.COM) 31
Boot disk, creating master 4
Bridges, IBM source routing 29
BUFFERS (NET.CFG) 20
C
CLEAR (ROUTE.COM) 32
CONNECTOR (NET.CFG) 19
Connector setting, 3C503 board 5
D
DEF (ROUTE.COM) 32
DMA (NET.CFG) 11
E
EMSNETx.EXE, expanded memory
shell file 23
Expanded memory shell 23
Extended memory shell 23
F
FRAME (NET.CFG) 15
G
GBR (ROUTE.COM) 32
H
Hardware, workstations supported
3
I
IBM Token-Ring network bridge 29
IBM Token-Ring Source Routing
Driver
guidelines for using 29
installing with DOS ODI 30
using with ROUTE.COM 30
INT (NET.CFG) 12
IPXODI
copying to master workstation
diskette 23
loading and unloading 23
removing parts of 24
L
LAN drivers
accessing information about 6
configuration options 9
drivernames 10
loading 4
NET.CFG options 9
supporting multiple protocols 1
unloading 6
LAN SUPPORT, adding device
drivers for 4
LAN WorkPlace for DOS 3
LANSUP.COM driver 4
LINK STATIONS (NET.CFG) 17
Link support options (NET.CFG)
20
LSL.COM 2, 4, 6
M
MAX FRAME SIZE (NET.CFG) 18
MBR (ROUTE.COM) 33
MEM (NET.CFG) 13
Memory
saving 24
setting for NET.CFG 13
MEMPOOL (NET.CFG) 20
N
NET.CFG
conventions 7
creating 5
example 7
options 8, 9
using with SHELL.CFG 26
NETx.COM on master workstation
diskette 23
NODE ADDRESS (NET.CFG) 14
NODES (ROUTE.COM) 33
P
PORT (NET.CFG) 13
PROTOCOL (NET.CFG) 16
Protocol, options in NET.CFG 21
protocol, unloading 6
R
Remote boot 25
Remote Diagnostics Responder,
unloading 24
REMOVE (ROUTE.COM) 33
ROUTE.COM 30
S
SAPS (NET.CFG) 17
Shell files 23
SHELL.CFG 26
SLOT (NET.CFG) 14
Source routing driver 29
SPX, unloading 24
T
Troubleshooting, installation 6
X
XMSNETx.EXE, extended memory
shell file 23
User Comments
Novell manuals and Novell products
We at Novell would like to hear from you if you have comments about our
manuals and products, or have suggestions for improving them. Please
address responses to
Novell, Inc.
NPD Technical Publications
122 East 1700 South MS C-24-1
Provo, UT 84606 USA
Please indicate the relevant chapters and page numbers and other
pertinent information as requested below.
Product Name:
Manual Name: ODI for DOS User's Guide
Part Number: 100-000871-002
Your Name:
Company Name:
Address:
City: State/Province:
Country: Zip/Postal Code:
Phone Number: ( )
FAX Number: ( )
Comments or suggestions